Snowflake Cortex ML-Based Functionsを使った時系列予測について確認した

データアナリティクス事業本部 機械学習チームの鈴木です。

この記事はSnowflake Advent Calendar 2023シリーズ2の10日目です。

現在プレビュー版にて提供中のSnowflake Cortex ML-Based Functionsを使った時系列予測機能について、ガイドやクイックスタートの内容を踏まえつつ、機能の利用イメージを掴むためのポイントになりそうな点をまとめます。

はじめに

Snowflake Cortex ML-Based Functionsの時系列予測について

Snowflake組み込みクラスであるFORECASTを使用し、勾配ブースティングマシンを使用した予測アルゴリズムを一つのSQLだけで学習可能で、推論も同じく一つのSQLだけで実行できます。

Snowflakeで時系列予測を行うためのほかの有力な候補としては、Snowpark MLがあります。『クイックスタートでSnowpark ML Modelingを学んだのでポイントをご紹介』ではSnowpark MLでXGBoostを使った回帰問題について触れました。Snowpark MLとの違いとしては、ML-Based Functionsが特徴量を自動生成してくれる点が大きいかと思います。また、Snowpark MLの場合は作成したモデルをUDFにデプロイするとか、シリアライズしてステージに配置しておくとか工夫をする必要がありますが、ML-Based Functionsはモデルを作成してしまえば、SQLでCALLで呼び出してそのまま使えるのもポイントとして挙げられます。

特徴量としては以下をそのままもしくは自動生成して利用ができます。

• 過去のターゲットデータの自己回帰ラグ
• 過去のターゲットデータの移動平均
• タイムスタンプデータから自動的に生成した周期的なカレンダー特徴量（曜日や週番号など）
• ターゲット値に影響を与えた可能性のある追加列

この記事で参考にした資料について

公式のガイドとクイックスタートを参考にしました。

ガイドは以下のページが提供されています。非常に詳しく仕様や使い方が記載されており、Snowflake側での予測アルゴリズム改良時について留意しておく事項についても記載されているのでぜひご確認ください。

クイックスタートも以下のものが提供されています。Snowflake Cortex ML-Based Functionsには記事執筆時点では時系列予測のほかに異常検出とContribution Explorerの機能も提供されており、このクイックスタートでは時系列予測と異常検出が説明されていました。この記事では時系列予測部分を試してみて分かったポイントを中心に記載します。

以下では、上記資料に記載のコードを引用した際には引用元を記載します。ライセンスは引用元の資料にしたがいます。

ポイントと思ったところのご紹介

モデルの作成

モデルの作成は、単一時系列および複数時系列の両方で可能でした。

基本となる単一時系列の例

モデルの作成はCREATE SNOWFLAKE.ML.FORECASTを使用してできました。

以下はクイックスタートの時系列モデルの作成例です。

入力データはSYSTEM$REFERENCEでのテーブルの参照を指定し、TIMESTAMP_COLNEMAとTARGET_COLNAMEで必須のデータ項目を指定しました。

ガイドの『Forecasting on a Single Series with Exogenous Variables』に記載があるように、ターゲット値に影響を与えた可能性のある追加列は特に指定する必要はなく、入力データに含まれているカラムのうち、TIMESTAMP_COLNEMAとTARGET_COLNAME以外のものが自動的に追加列と認識されるとのことでした。代わりに、入力に使いたいテーブルに不要な列が含まれている場合は、入力のためのビューなどを作る必要がありそうです。

複数時系列の例について

上記の例は単一時系列の例ですが、複数時系列を扱うこともできることが紹介されています。

複数時系列の場合は、『Forecast on Multiple Series』に記載のように系列の列として数値とテキストを含む VARIANTを指定する必要があります（FORECASTクラスのコンストラクター引数の項目を参照）。

ガイドの例では[ 1, "jacket" ]のような値を持つSTORE_ITEM列を作成し、CREATE SNOWFLAKE.ML.FORECASTのうちSERIES_COLNAMEで指定していました。

-- https://docs.snowflake.com/en/user-guide/ml-powered-forecasting#forecast-on-multiple-series
-- より2023/12/9に引用
CREATE SNOWFLAKE.ML.FORECAST model3(INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v3'),
                                    SERIES_COLNAME => 'store_item',
                                    TIMESTAMP_COLNAME => 'date',
                                    TARGET_COLNAME => 'sales'
                                   );

ここはそういう仕様なんだなと理解して、仕様にあったデータを作成するビューなどを作成すると良さそうです。

推論の実行

<モデル名>!FORECASTで推論を実行できました。

モデルが単一時系列なのか複数時系列なのかにより、呼び出し時のインターフェースが異なるため、以下のガイドで確認すると良さそうでした。

• FORECAST - <モデル名>!FORECAST | Snowflake Documentation

推論は、学習に仕様した入力データの最後の日付より、FORECASTING _PERIODSで指定した期間を生成してくれ、推定される結果の間隔は入力データから自動的に決まります。

推定の開始期間は入力データに依存するため、定期的にモデルは学習しなおす運用を想定した方が良さそうでした。必須のデータ項目以外に追加列があるモデルだと、推論時にINPUT_DATAを渡せるようでしたが、あくまでも必須項目以外の値を考慮した場合の結果を生成するための項目で、予測する期間には影響がないように見えました。

モデルの一覧と削除

モデルの一覧と削除もSQLより行いました。

現状では、作成したモデルはSnowsightではなく、SHOW SNOWFLAKE.ML.FORECASTで確認できました。

# 作成されたモデルを一覧
SHOW SNOWFLAKE.ML.FORECAST;

# 作成されたモデルを削除
DROP SNOWFLAKE.ML.FORECAST モデル名;

例えばクイックスタートではimpressions_forecastモデルを作成しましたが、以下のようにモデルを確認できました。

このようにSnowsightからは見えませんでした。

ウェアハウスの選定

ガイドの『Selecting a Virtual Warehouse』に具体的な記載があってとても参考になりました。

記事執筆時点でのガイドの記載で、以下のウェアハウス選定基準がポイントと思いました。

• 訓練データに追加列が含まれていない場合、データセットが5万行以下であれば、標準ウェアハウスで訓練できる。
• データセットが5万行を超えた場合はSnowparkに最適化されたウェアハウスの仕様を検討する。
• 訓練データに追加列が含まれている場合、それが5つ以上であれば、標準ウェアハウスではメモリの都合で最大行数に影響が出てくる可能性がある。
• 単一系列データの場合、ウェアハウスサイズが大きくなっても、訓練時間が短縮されたり、メモリ制限が高くなったりすることはない。
• 複数系列のデータの場合、ウェアハウスサイズが大きさは訓練速度に対して影響が大きく、かなり高速に訓練される。

正確な記載についてはぜひガイドをご確認ください。

特徴量重要度の確認

<モデル名>!EXPLAIN_FEATURE_IMPORTANCEで特徴量重要度も確認できました。

上の結果では、移動平均などターゲット変数のラグ以外のすべての変換が集約されたaggregated_endogenous_featuresが重要とされています。

この結果を使って、モデルがどの特徴量を重要として学習しているのか確認することで、モデルの挙動や学習データへの洞察を深めることができます。

推論結果の可視化

SnowsightのSQLワークシートで実行している場合は、以下のようにACTUALとFORECASTの系列を図示することで、それぞれの推移を確認することができました。

図示するデータの追加などは、以下のようにチャートのデータにAdd columnなどで追加しました。

最後に

Snowflake Cortex ML-Based Functionsを使った時系列予測を試してみたのでご紹介でした。

クイックスタートでは手軽に、ガイドでは非常に詳しく使い方を学ぶことができたので、すぐに使いこなせそうでした。

推論は入力データの最後からと日付が固定になりそうだったので、運用面では定期的な再学習を考えておいた方が良さそうでした。

非常に使いやすく便利な機能なので、GAになるのが待ち遠しいです。